[RV64_DYNAREC] Support VMOVDQU opcode - #4224

Is there any specific reason to add the unaligned path?

I added that because MOVDQU handles unaligned paths, and legacy rv64 cores such as SiFive U74 lack hardware unaligned access support. Does box64’s rv64 backend plan to only target CPUs supporting hardware unalgined access?

No, all CPU are targeted to be supported.

I think the question was more about: was this (unaligned) case needed, and is this (unaligned) branch tested?

No, all CPU are targeted to be supported.

I think the question was more about: was this case needed, and is this branch tested?

Sorry, I’m still confused and would appreciate some clarification.

My understanding of the IF_UNALIGNED(ip) macro is: By default, it assumes the CPU supports hardware unaligned access and takes the aligned‑path. If the CPU does not support it, an exception is triggered. The ip is recorded in a hash table, and the corresponding dynarec block is marked invalid. Code generation for this ip will take the unaligned‑path on the next emit time.

I notice that an unaligned‑path exists for MOVDQU Ex, Gx, but not for MOVDQU Gx, Ex. What is the difference between them? As I see it, when Ex is a memory operand in MOVDQU Gx, Ex, it can also be unaligned and should therefore require unaligned‑access handling. Could it be that sigbus_specialcases only handles store unaligned‑access cases, but not load unaligned‑access cases?

All risc-v CPUs I have available support unaligned access. So I changed IF_UNALIGNED(ip) to if (1) to force execution through the unaligned‑path for testing.

Yes, your understanding of the IF_UNALIGNED macro is correct (also, the block is forced as dirty so it will be regenerated at next run)

The process is: IF_UNALIGNED are always implemented in a "as-needed" process. You have a repeated SIGBUS that would benefit from IF_UNALIGNED, you implement it. Else, no need to clutter the code with IF_UNALIGNED cases.

All you hardware support unaligned access? You mean unaligned access to hardware mapped memory, like GPU memory? because the unaligned stuffs is for this case: unaligned access to memory mapped GPU memory (like on AMD gpu for example).

The process is: IF_UNALIGNED are always implemented in a "as-needed" process. You have a repeated SIGBUS that would benefit from IF_UNALIGNED, you implement it. Else, no need to clutter the code with IF_UNALIGNED cases.

Can I understand it this way?

1. If VMOVDQU is only invoked a few times, there is no need to add IF_UNALIGNED. We can just take the SIGBUS trap and fall back to single‑byte access every time.
2. If the VMOVDQU instruction gets called heavily, IF_UNALIGNED should be added to avoid frequent SIGBUS traps.

When I mentioned my cpus supporting unaligned accesses earlier, I was only considering normal cacheable memory. This does not cover device memory, atomic‑region memory, and other such memory types.

The process is: IF_UNALIGNED are always implemented in a "as-needed" process. You have a repeated SIGBUS that would benefit from IF_UNALIGNED, you implement it. Else, no need to clutter the code with IF_UNALIGNED cases.

Can I understand it this way?

1. If VMOVDQU is only invoked a few times, there is no need to add IF_UNALIGNED. We can just take the SIGBUS trap and fall back to single‑byte access every time.
2. If the VMOVDQU instruction gets called heavily, IF_UNALIGNED should be added to avoid frequent SIGBUS traps.

When I mentioned my cpus supporting unaligned accesses earlier, I was only considering normal cacheable memory. This does not cover device memory, atomic‑region memory, and other such memory types.

Yes. The unaligned path is an optimisation. Too many SIGBUS will hurt the performances badly. But if there is no SIGBUS, why clutering the code with useless branch...

The process is: IF_UNALIGNED are always implemented in a "as-needed" process. You have a repeated SIGBUS that would benefit from IF_UNALIGNED, you implement it. Else, no need to clutter the code with IF_UNALIGNED cases.

Can I understand it this way?

1. If VMOVDQU is only invoked a few times, there is no need to add IF_UNALIGNED. We can just take the SIGBUS trap and fall back to single‑byte access every time.
2. If the VMOVDQU instruction gets called heavily, IF_UNALIGNED should be added to avoid frequent SIGBUS traps.

When I mentioned my cpus supporting unaligned accesses earlier, I was only considering normal cacheable memory. This does not cover device memory, atomic‑region memory, and other such memory types.

Yes. The unaligned path is an optimisation. Too many SIGBUS will hurt the performances badly. But if there is no SIGBUS, why clutering the code with useless branch...

It seems Box64 has made quite a few trade‑offs. I have removed the unaligned‑path. Please help review again. Thanks.